资产上云是一种趋势，云凭借高算力、易运维、资源拓展方便，安全性相对较高等优点，被逐渐使用广泛云原生是云计算发展的一种趋势，他不是一个具体的技术，而是一种大的方式，类似于TCP/IP协议一样。随着越来越多的业务上云，以及近年来针对云服务的攻击愈发激烈，所以云原生安全是未来安全领域的一大热点方向，虽然不会取代终端安全，但是会抢占绝大多数的终端安全资源和岗位。
ctrl+.可以解决输入的符号都变西文的问题
是什么
云计算的下半场。终端安全对应的应该是云原生安全，而不是云安全，因为部分云安全仍谈具有终端安全的特性，只不过是将之前的本地部署变到了云服务器部署，实际的安全和运维状态发生了部分技术上的变化，而总体思路还是传统终端安全的思路。
概况
云原生，就是从云上原生的技术、服务、软件等等，这些东西是云生出来的，他们天生具有云的特性，而不是简单的上云运动（将之前跑在本地或者本地服务器的服务，通过硬盘挪移，文件上载等传统形势，把物理基本从自己的服务器换到了云厂商提供的服务器上）。
CNCF是中华穿越火线联盟或者是指云原生基金会。
这个基金会主要的目的就是推进一个云原生的标准化进程，因为只有标准化的云原生架构构建，才能推进之后的云原生快速发展。该基金会在2017年提出了一个开放容器标准(OCI)。
组成
云原生的组成或者说是任何计算机的架构组织，都可以分为硬件组织和软件组织，这里我基于自己的理解来分类云原平台的组成。
硬件
云原生云原生，最重要的就是云，这个云就是指的是一些厂商的提供的对外开放的服务器，所以这里最重要的就是服务器，需要强大的服务器硬件来存放这些云服务。这就需要强大的CPU和内存、硬盘等硬件设施。
除了服务器基础，还需要粗大的网线和交换机来支撑住这些大量的访问请求，和网络通信带宽。
同时需要从根本上做好安全保护，需要独立的机房和自动化的冷却系统和异地容灾系统，这都是需要注意的地方。还有就是先进有力的安保系统，强大的保安可以挡住绝大多数的物理攻击和破坏。
软件
目前主流的方案是：
容器 + 管理系统
在落实下来一般就是docker负责容器和镜像，然后搭配k8s进行统一的调度和管理。
docker自己作为容器，缺点是无法大规模的部署和操作；k8s就是负责来提供一个容器和宿主机之间的中间层，来批量的部署、管理、交互这些容器。
特征
轻快和不变的基础设施
云的支撑基础设施是容器，容器生命周期短、占用资源少，所以既清又快，一般情况下升级服务都是直接更新镜像而不是更新容器内的应用。
通过编排系统下载新的镜像并启动相应的容器，并将就的容器删除
这种模式称为“不变的基础设施”
弹性的服务编排
云原生的关注点是业务，初衷也是为了让技术人员更多的关注业务，不要再平台运维上耽误过多的时间。服务编排（orchestration）可以按需弹性的控制服务的位置，容量，版本等内容
开发运营一体化
就是常说的Devops，将软件开发和IT运营结合的实践
历史
这个东西之前还存在两种东西
- 传统开发的“瀑布式模型”
- 敏捷开发
瀑布式模型：
就是一步步往下走的模式，但是如果客户在中途提出了新的需求或者改变了策略，瀑布就需要倒流回去，后面的步骤就没活干，前面的步骤就累到死。
这时候就推出了新的模型：Agile Development、敏捷开发：
就是把大项目变成小项目，把大时间点变成小时间点。这样加强合作，就可以提高效率，应对突发改变
因为他使用了小步快跑的模式，所以当上一步出现问题时，不会造成剧烈的影响，就可以直接下一个版本进行改正，减少出现重大失误的情况，而且因为步子小，出现错误的修复成本也小。
但是这种方式从上图中可以看到，开发和测试合并了，但是运维还是祖传的模式，旧模式适应新框架是弱智的选择，而且还存在一定的推诿扯皮，所以就产生了devops这种开发模式
devops
DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
他是对敏捷开发的有益补充。正因为他的抽象的概念，所以有人将他认为是一种宗教也在情理之中。
误区：DevOps，就是Dev+Ops嘛，把两个团队合并，或者将运维划归开发。
在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。
对应到阶段图就是
将三者进行合并，他的重点是消除开发和运营的矛盾
微服务
顾名思义，就是将一个大的功能主体进行拆分成细小的服务个体，针对每一个个体进行开发和测试。微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。
开始的时候组件一般集中的部署在服务器上，后来随着web server标准的推出，应用按照标准的服务交付，应用间通过RPC（远程服务调用）的方式进行交互，形成了面向服务的架构（Service-Oriented Architecture SOA）。
微服务应用到云原生上的表现形势就是，传统的单体应用功能被拆分，这使得每一个服务聚焦在自己的功能上，然后利用“应用编排”进行组装，进而实现等价于传统个体的复杂功能，这提高了代码的复用性，再后续的升级中，不用去关注代码的内部实现，只需要能用即可（条条大路通罗马）
无服务
Serverless，这是一个抽象的模型，基于代码和计算任务执行的云计算。与之相对的是基于服务器的计算模式。是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。
无服务器方案中仍然有服务器，但它们已从应用开发中抽离了出来。云提供商负责置备、维护和扩展服务器基础架构等例行工作。开发人员可以简单地将代码打包到容器中进行部署。部署之后，无服务器应用即可响应需求，并根据需要自动扩容。公共云提供商的无服务器产品通常通过一种事件驱动执行模型来按需计量。因此，当无服务器功能闲置时，不会产生费用。
可以看作是一个服务器和应用的中间层，类似于shell一样，开发人员只需要将自己的服务进行部署即可，省去了复杂的运维和配置过程，而这些过程是由提供商负责的，专业的人做专业的事，提高效率。
总结
云原生是以云的模式管理和部署资源，而不是简单的将资产放到云端的过程。用户看到的不是IT系统或者是虚拟主机之类的东西，而是一个个独立但是有联系的业务单元，开发者的精力重新回归到业务本身。
微服务、Serverless是云原生理念的核心体现；容器、编排、服务网格是云原生的支撑技术。
容器历史
主要和最常使用的就是docker了。
linux原生隔离
linux在07年就根据自己的内核特性，推出了两种隔离特性，namespaces和cgroup。并且根据这俩特性推出了一个容器机制：Linux Container（LXC）并且进行推广使用，但是这个技术有局限性，他是对软件层面的容器打包，适合在相同配置的机器间进行移动，不能在不同配置的主机间移动，因为他只是打包了软件层，需要的一些libc没有得到打包。
Namespaces
进程资源隔离限制。这里控制了他可以看到哪些进程，可以看到哪些网络信息等。
每个namespace都有一个独立的全局资源实例
Cgroup
进程资源使用限制（control groups）。来自linux内核的功能，控制可以用多少的内存资源，多少的CPU资源等。
docker
docker在上述的linux原生的基础上，不仅仅打包了文件系统，同时还打包了一些底层运行库和OS的文件系统，保证了在容器上的应用可以任意迁移，一次开发持续使用的目的。
但是在一些关于需要用到内核服务的应用上，docker依旧存在不小的弊端，因为他还是基于宿主机的内核来为自己提供服务的。
docker的镜像和传统的镜像还是有不小的区别的，虽然都是镜像。在云安全中，镜像投毒也是一种危害广泛的攻击方式。
Docker 镜像就是一个只读的模板。一个镜像可以包含一个完整的 ubuntu 操作系统环境，里面仅安装了 Apache 或用户需要的其它应用程序。docker通过镜像创建容器，容器依赖于镜像。
注：镜像是只读的，容器在启动的时候创建一层可写层作为最上层。
所以可以通过更新镜像的方式来更新服务。